時系列データの保存先をDynamoDBからTimestreamへ移行すべきか検討してみる

CX事業本部@大阪の岩田です。このブログはJapan APN Ambassador Advent Calendar 2020の20日目の記事になります。そもそもアンバサダーって何？という方はこちらの記事をご覧下さい。

APN Ambassadorってなんだ？

この記事では2020年10月にGAされたフルマネージドな時系列データベースTimestreamについて考察します。

想定するシナリオ

具体的に以下のようなユースケースにおいてDynamoDBを利用しているシステムがあり、DynamoDBからTimestreamに移行すべきか？という判断材料についてまとめていきます。

(シナリオ)

• AWS IoTに接続されたIoTデバイスから時系列データを収集したい
  • 例えば温度だったり、位置情報だったり、テレメトリデータだったり
• 収集したデータをWeb API経由で同期的に、かつニアリアルタイムで取得したい
  • データが発生してからWeb APIで取得可能になるまで1時間もかかるのはNG
• APIで取得したデータを利用してブラウザ上にグラフを描画したい

AWS IoTはサーバーレスなシステムとの相性が良いことから、このようなユースケースではAPI GW(もしくはAppSync)のバックエンドにLambdaを置いて、データストアとしてDynamoDBを利用することが多かったのではないでしょうか？DynamoDBが100%要件にマッチするというわけではないですが、他のサービスよりはDynamoDBの方がマッチしそうです。

他のデータベースを採用した場合の要件とのギャップや構成上のデメリットについて簡単に考えてみましょう。

• S3 & Athena、IoT Analytics
  • クエリが非同期になるのでAPIで同期的にデータを取得したいという要件にマッチしない
• RDS(RDB)
  • スケールアウトに課題があり、IoTデバイスのデータストアとして利用するには難あり。Lambdaとの相性も悪い
• Amazon ES
  • クラスタ管理が面倒

ざっくりこんな感じでしょうか。DynamoDBであれば同期的にクエリを実行できますし、スケールアウトしやすくLambdaとの相性も良いです。フルマネージドなサービスでDB管理の負荷も低いので、Timestream抜きで考えると、DynamoDBが無難な選択肢ではないでしょうか。

しかし、現在ではここにTimestreamという選択肢が増えています。これからシステムを構築する場合、データベースにはDynamoDBとTimestreamのどちらを採用すべきでしょうか？もしくは既にDynamoDBで構築済のシステムをTimestreamに移行すべきなのでしょうか？最終的な判断は当然ユースケース次第になるのですが、判断材料として2つのデータベースを比較していきたいと思います。

Timestreamの概要についておさらい

DynamoDBとTimestreamを比較する前にTimestreamがどういうサービスなのか概要をおさらいしておきましょう。

ディメンションとメジャー

Timestreamと他のデータベースを比較したときに、特徴的なのがレコードの形式です。Timestreamにおける1レコードは以下の要素で構成されます。

• ディメンション
  • 時系列データのメタデータです。例えばIoTデバイスのデバイスIDなどがディメンションに相当します。
• メジャー
  • 時系列データの計測値です。例えばIoTデバイスが計測した温度やCPU使用率などはメジャーに相当します。メジャーはさらに名前と値から構成されます。
• タイムスタンプ
  • メジャーが計測された時のタイムスタンプです。時系列データベースであるTimestreamでは、各レコードは必ずタイムスタンプを持ちます。

例えばデバイスごとに時系列のCPU使用率と温度を収集するとします。RDBやDynamoDBだとデータの格納イメージは以下のようになります。

device_id	time	cpu	temperature
test-device-1	2020-12-19 12:00:00.000000000	50.00	10.1

それに対してTimestreamは以下のような形式でデータを格納します。

device_id(ディメンション)	time(タイムスタンプ)	measure_name(メジャー)	measure_value::double(メジャー)
test-device-1	2020-12-19 12:00:00.000000000	cpu	50.00
test-device-1	2020-12-19 12:00:00.000000000	temperature	10.1

計測対象が増えた場合にカラムやアトリビュートが横に増えていくのか、レコードが縦に増えていくのかという違いがあります。

ストレージ

Timestreamはメモリストアとマグネティックストアという2種類のストレージを持ちます。それぞれ以下のような役割を持ちます。

• メモリストア
  • 新しいデータを保存するためのストレージ
  • ある時点のデータを高速に抽出するようなクエリに最適化されている
• マグネティックストア
  • データを長期間保存するためのストレージ
  • 分析クエリをサポートするように最適化されている

各ストレージにはデータの保持期間が設定でき、設定したデータ保持期間とレコードのタイムスタンプに応じてレコードの保存先がメモリストア　→　マグネティックストアと遷移し、マグネティックストアのデータ保持期間を超過したレコードは削除されます。

現在はメモリストアとマグネティックストアの2種類でストレージが構成されていますが、将来的にはこの2つの中間に位置するSSDストアの追加が予定されています。

クエリ

TimestreamではSQLを利用してデータをクエリできます。SQLのサポートも手厚く

• JOIN(現状SELF JOINのみ対応 ※別テーブルとのJOINも可能になりました【アップデート】Timestremで複数テーブルのJOINや高度な時系列関数が利用可能になりました)
• サブクエリ
• CASE文
• WITH句
• 集約関数
• Window関数
• 時系列関数

などなど様々な機能が利用できます。

これがIoT AnalyticsだとJOINやWITH句が使えないためSQLが使えるという魅力が薄れてしまうのですが、TimestreamではSQLをフル活用した分析が可能です。

DynamoDBとTimestreamの機能比較

ここからDynamoDBとTimestreamそれぞれの機能について比較していきます。それぞれのメリット/デメリットと自身のユースケースを検討した上で最終的に判断頂ければと思います。

以後の内容は2020年12月時点のサービス仕様に基づいています。今後のアップデートにより仕様が変わる可能性があることにご注意下さい。なお、DynamoDBに関してはオンデマンドモードを前提とした比較になります。

共通点

まずは共通点から見ていきましょう。DynamoDBとTimestreamに共通するメリットは以下のような項目が挙げられます。

• 従量課金
  • 後ほど料金の比較も行いますが、両サービスとも従量課金が原則です。RDSのようにインスタンスを上げているだけで課金されてるということはありません。
• 自動スケール
  • 両サービスともインスタンス管理の概念がありません。負荷に応じてクラスターにインスタンスを追加したり、インスタンスサイズを変更したりといった煩わしい管理作業は不要です。サービス基盤側で自動的にスケールしてくれるようになっています。
• 自動バージョンアップ
  • サービスのバージョンアップやパッチ適用も全て基盤側にお任せです。RDSのようにメンテナンスウインドウを定義して...といった管理は不要です。
• スキーマレス
  • データベースのスキーマを事前にカッチリ決めておく必要はありません。DynamoDBであればアトリビュート、Timestreamであればメジャーとディメンションに自由に項目追加が可能です。RDBのようにALTER文を流して列追加する必要はありません。
• VPC不要
  • 両サービスともVPC不要のサービスです。Lambdaからも利用しやすいです。
• TTLによるデータの自動削除
  • 両サービスともTTLの概念があり、時系列データを自動的に削除可能です

これらのメリットに魅力を感じてDynamoDBを利用している方はTimestream移行後も同様のメリットが享受できます。

Timestreamの方が強い点

ここからはDynamoDBと比較したTimestreamの優位性として、以下のような項目が上げられます。

• 集計処理
  • さきほどご紹介したようにTimestreamではSQLが利用できます。デバイスごとに平均CPU使用率を求めたいといった要件にも集約関数を利用することで簡単に対応可能です。DynamoDBだとトランザクションやDynamoDBストリームと連携して集計用のテーブルをメンテナンスするか、クエリで取得したアイテムをアプリケーション側で集計する必要があります。
• 柔軟な検索
  • Timestreamではタイムスタンプ、ディメンション、メジャーを指定した柔軟な検索が可能です。サブクエリも利用できるので集計処理の結果によってデータを抽出するといった検索要件にも簡単に対応可能です。DynamoDBでクエリを実行するためにはインデックスが必須になりますし、インデックスを用いたクエリもTimestreamほどの柔軟性はありません。
• 時系列処理
  • Timestreamは時系列処理に特化したデータベースなので、当然時系列処理に強みを持ちます。例えば欠損値を保管したり指定した時間間隔で集計結果を丸めるといったことが可能です。例えばデバイスから1分に1回温度情報が送信されてくるとします。この送信されてきた温度情報を1時間ごとの平均値に集計する場合、DynamoDBではどのような実装になるでしょうか？アプリケーション側に集計ロジックを実装する必要があります。これがTimestreamであれば時系列関数を利用するだけで簡単に1時間ごとの平均値に丸めることができます。

Timestreamの方が弱い点

さきほどと逆にDynamoDBにできてTimestreamにできないことを見ていきましょう

• レコードの削除
  • Timestreamでは手動のレコード削除が行えません。レコードが削除されるのはデータ保持期間経過後の自動削除のみです。
• バックアップ/リストア
  • Timestreamはテーブルやデータベースのバックアップ/リストア機能を持ちません。データのバックアップが欲しければクエリの実行結果をチマチマとファイルに出力するような対応が必要です。
• エクスポート
  • バックアップとも似ていますが、テーブルの中身をS3にエクスポートするといったこともできません。
• 過去データの投入
  • Timestreamではメモリストアに設定されたデータ保持期間を経過しているレコードは登録することができません。メモリストアに設定可能な最長のデータ保持期間は1年なので、1年以上前のタイムスタンプが設定されたデータはTimestreamには登録不可能ということになります。
• トランザクションが無い
  • DynamoDBで利用できるTransactWriteのような概念はありません。レコードを書き込む際に、一部の書き込みのみ失敗するということも起こりえます。
• データ型が少ない
  • Timestreamで扱えるデータ型はスカラー値のみで、対応しているデータ型は以下の4種類です。
    • BIGINT
    • BOOLEAN
    • DOUBLE
    • VARCHAR

  DynamoDBのMap、Listのようなドキュメント型やセット型には対応していません。

• 東京リージョンで利用不可
  • 機能的なデメリットではないのですが、Timestreamは東京リージョンでは利用できません。東京リージョンのLambdaからバージニアリージョンのTimestreamにクエリするといった構成も可能ですが、リージョン跨ぎによるレイテンシーとデータ転送料金が懸念となります。

DynamoDBというサービスは歴史が長く、ここで挙げたような基本的な機能以外にもグローバルデータベースやDAXのように特定のユースケースで利用できる様々な機能を持っています。連携可能な別AWSサービスも豊富です。このあたりはDynamoDBに対するTimestreamの明確なディスアドバンテージと言えるでしょう。

DynamoDBとTimestreamの料金比較

最後に料金面での比較を見ておきましょう。バージニアリージョンの料金で比較します。

Timestremの料金

Timestreamの料金体系は以下の通りです。詳細は公式ドキュメントをご参照下さい。

Amazon Timestream の料金

• 書き込み
  • 1KBサイズの書き込み100万件あたり0.50USD
• ストレージ
  • メモリストア
  • 1GB/1時間 0.01USD
  • SSDストア(近日提供予定)
  • 1GB/1日 0.01USD メモリストアの1/24
  • マグネティックストア
  • 1GB/1月 0.03USD 1ヶ月30日換算でメモリストアの1/240
• クエリ
  • 1GBあたりのスキャン量 0.01USD
  • バイト数はメガバイト単位で切り上げられ、10MB未満のクエリは10MB と計算

※データ転送に対する課金は割愛します

当たり前ですが、ストレージの課金はメモリ、SSD、マグネティックの順に高額になります。注意しておきたいのがクエリの課金です。10MB未満のクエリも10MBとして切り上げられるので、ちょっとデータの中身を確認しようとselect * from table limit 10のようなちょっとしたクエリを何度も実行しているうちに、意外と課金が発生しているということがあります。DynamoDBのGetItemのような単一レコードの取得ではなく、あくまで集計等の利用用途を想定した課金体系に見えます。

DynamoDB(オンデマンドモード)の料金

続いてDynamoDBの料金体系です。

オンデマンドキャパシティーの料金

Timestreamとの比較が目的なので、Timestreamと同様の課金項目のみ抜き出しています。DAXのようなDynamoDB固有の課金項目とデータ転送量は割愛しています。

• 読み込み/書き込みリクエスト
  • 書き込み要求ユニット100万あたり 1.25USD
  • 読み出し要求ユニット100万あたり 0.25USD
• データストレージ
  • 毎月1GBあたり0.25USD(毎月最初の25GBまでは無料)

料金比較

各課金項目について料金を比較してみましょう

書き込み料金

DynamoDBの課金単位は書き込み要求ユニットに対する課金ですが、トランザクションを利用しない場合は1K未満のアイテム書き込み=1書き込み要求ユニットとなります。ここではシンプルに1K未満のアイテムを書き込む前提での比較とします。また、TimeStreamは1レコードで複数のメジャーを登録できないため、DynamoDBの1アイテムをTimestreamではNレコードで表現することになります。Timestreamへの書き込みはDynamoDBの1アイテム相当のレコード群を一括で書き込み、かつNレコードの合計サイズが1K未満に収まるという前提で比較します。

DynamoDB、TimeStreamそれぞれ1回の書き込みが1K未満に収まるという前提だとTimeStreamの方が料金は安いと言えます。

DB	100万アイテム/レコードの書き込み料金
DynamoDB	1.25USD
Timestream	0.50USD

読み込み料金

比較が難しい部分ですが、DynamoDB、Timestream共に1回のクエリでDynamoDBのクエリ結果セット上限である1MB分のデータを取得する前提で比較します。

DB	100万クエリあたりの料金
DynamoDB	32USD　※(1M/4K) × 0.5 → 128読み出し要求ユニット/クエリ1回)
Timestream	97.65USD ※ 10M(1Mから切り上げ) × 100万クエリ / 1024M × 0.01USD

最低10Mに切り上げられるという仕様がネックになりTimestreamの方が高くついています。ただし1回のクエリで取得する結果を10Mで再度シミュレーションすると(結果セット1Mの上限があるためDynamoDBはクエリを10回分割実行)、Timestreamの料金は変わらないのに対してDynamoDBの料金は10倍になるため、今度はTimesreamの方が安くなります。

DB	100万クエリ(DynamoDBは1000万クエリ)あたりの料金
DynamoDB	320USD　※(10M/4K) × 0.5 → 1280読み出し要求ユニット/クエリ10回)
Timestream	97.65USD ※ 10M × 100万クエリ / 1024M × 0.01USD

ざっくりした傾向としては軽いクエリが多いならDynamoDBの方が安く、重いクエリが多ければTimestreamの方が安いと考えると良さそうです。

ストレージ料金

DynamoDBの無料枠を無視しつつ、1ヶ月30日換算で課金単位を揃えて比較してみましょう。

DB	1GB1ヶ月あたりの料金
DynamoDB	0.25USD
Timestream(メモリストア)	25.92USD ※0.036USD×24時間×30日
Timestream(SSDストア)	0.3USD ※0.01USD×30日
Timestream(マグネティックストア)	0.03USD

DynamoDBのストレージ料金はTimestreamのSSDストアより若干安いという位置づけになります。実際はDynamoDBには1月あたり25Gまでの無料枠があるので、そこの考慮も必要です。28.5Gのデータを1ヶ月保存するシナリオを考えるとストレージ料金は

• DynamoDB: (28.5G -25G) × 0.25USD → 0.875USD
• Timestream(マグネティックストア): 28.5G × 0.03USD → 0.855USD

となり、DynamoDBとTimestream(マグネティックストア)の料金がほぼ同一となります。これ以上サイズが増えていくとTimestream(マグネティックストア)のコストメリットが大きくなっていきます。

どちらが安いかと聞かれると、「データ量とTimestreamの各データストアのデータ保持期間次第」という回答になります。

まとめ

元々自分の関わっている案件がDynamoDBに時系列データを保存しており、Timestreamへの移行を検討する機会があったのでブログにまとめてみました。最終的にTimestreamへの移行は見送りとなったのですが、理由としてはバックアップ/リストアといった操作が行えないことによる運用フェーズの不安材料以外にも、レコードの削除や過去データの投入が行えないことによる開発生産性の低下といった懸念事項もありました。2020年末の時点ではこのような判断となりましたが、TimestreamはGA直後の新しいサービスであり今後の機能拡張によって、諸々の懸念事項が改善されていく可能性があります。今後もTimestreamの動向に注目して見守っていきたいと思います。